Amazon CloudWatch Synthetics Canary でリダイレクト時の動作を検証してみた

#CloudWatch Synthetics Canaries

Shiina

2024.08.02

こんにちは。テクニカルサポートチームのShiinaです。

はじめに

Amazon CloudWatch Synthetics Canary を URL 監視（外形監視）　としてシステム監視に利用されている方も多いのではないでしょうか。

監視対象 URL となる Web サイトの一時的なメンテナンスなどで別の Web サイトへにリダイレクトさせた場合、Amazon CloudWatch Synthetics Canary の実行結果はどうなるのか？と気になったので動作を検証してみました。

結論

監視対象 URL でリダイレクトが発生した場合、リダイレクト先となる Web サイトに対するレスポンスで判定されます。

リダイレクト元の Web サイトの 3xx 系レスポンスで判定されません。

リダイレクト先の Web サイトに到達できない場合やリダイレクト先で 2xx 系のレスポンス以外が返された場合、Amazon CloudWatch Synthetics Canary の実行は失敗します。

やってみた

環境準備

EC2 インスタンスを２台用意します。
Apache HTTP Server をインストールして、リダイレクト元となる Web サーバとリダイレクト先となる Web サーバを構築します。
リダイレクト元の Web サーバでリダイレクトの設定を行います。
/etc/httpd/conf/httpd.conf にリダイレクト先の Web サーバとなる EC2のパブリック IPv4 DNS 名を指定した Redirect ルールを記載設定します。

/etc/httpd/conf/httpd.conf

Redirect 302 /index.html http://xxxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com

httpd.conf の設定を反映します。

systemctl reload httpd

ローカル端末から curl コマンドでリダイレクト元となる Webサーバの EC2 のパブリック IPv4 DNS 名へアクセスしてみます。

curl -I -L "http://xxxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com"
HTTP/1.1 302 Found
Date: Thu, 01 Aug 2024 06:03:45 GMT
Server: Apache/2.4.61 (Amazon Linux)
Location: http://yyyyyyyyyyyyy.ap-northeast-1.compute.amazonaws.com
Content-Type: text/html; charset=iso-8859-1
Cf-Team: 21ae229f1f00008a4b62c5a400000001

HTTP/1.1 200 OK
Date: Thu, 01 Aug 2024 06:03:45 GMT
Server: Apache/2.4.61 (Amazon Linux)
Last-Modified: Wed, 31 Jul 2024 06:27:49 GMT
ETag: "34-61e853178f217"
Accept-Ranges: bytes
Content-Length: 52
Content-Type: text/html; charset=UTF-8
Cf-Team: 21ae22a00100008a4b62c81400000001

リダイレクトが発生していることを確認できました！

Canary の設定

次の通りに設定してみました。

名前：url-check
アプリケーションまたはエンドポイントのURL：http://リダイレクト元EC2のパブリック IPv4 DNS名
設計図：ハートビートのモニタリング
ランタイムバージョン：syn-nodejs-puppeteer-9.0

リダイレクト時の動作

それでは Canary の実行結果を確認してみます。
Untitled (2)

ステータスは成功となりました。

HAR ファイルタブから Status code を確認したところ、302 Found と 200 OK のレコードがそれぞれ記録されていました。

リダイレクト先となる Web サイトに対するレスポンスで判定されています。

リダイレクト先のWeb サイトに到達できない場合

今回はリダイレクト先の EC2 インスタンスに設定されているセキュリティグループで確認元である Canary の IP アドレスからの HTTP アクセスをインバウンドルールで絞ることにより、到達できないようにしました。

Canary の実行結果を確認してみます。
Untitled (3)

ステータスは失敗となりました。

ログタブよりログビューワーで詳細なログを見てみます。
Untitled (4)

リダイレクト元は 302 のレスポンスを返していますが、リダイレクト先で ERR_CONNECTION_TIMED_OUT が発生しています。

リダイレクト先の Web サイトで 2xx 系のレスポンス以外が返された場合

リダイレクト先のコンテンツで 403 Forbidden を発生させるため、Apache HTTP Server の設定で IP 制限をかけてみます。

ローカルループバックアドレスのみアクセスを許可する設定にします。

/etc/httpd/conf/httpd.conf

<Directory "/var/www/html">
    #
    # Possible values for the Options directive are "None", "All",
    # or any combination of:
    #   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
    #
    # Note that "MultiViews" must be named *explicitly* --- "Options All"
    # doesn't give it to you.
    #
    # The Options directive is both complicated and important.  Please see
    # http://httpd.apache.org/docs/2.4/mod/core.html#options
    # for more information.
    #
    Options Indexes FollowSymLinks

    #
    # AllowOverride controls what directives may be placed in .htaccess files.
    # It can be "All", "None", or any combination of the keywords:
    #   Options FileInfo AuthConfig Limit
    #
    AllowOverride None

    #
    # Controls who can get stuff from this server.
    #
    Require ip 127.0.0.1
    # Require all granted
</Directory>

httpd.conf の設定を反映します。

systemctl reload httpd

Canary の実行結果を確認してみます。
Untitled (5)

ステータスは失敗となりました。

ログタブよりログビューワーで詳細なログを見てみます。
Untitled (6)

リダイレクト元は 302 のレスポンスを返していますが、リダイレクト先で 403 Forbidden が発生しています。

まとめ

今回は Amazon CloudWatch Synthetics Canary でリダイレクト時の動作を検証してみました。
リダイレクト時にはリダイレクト先を追跡する結果となりました。
SaaS 監視サービスや監視ツールの設定によっては URL 監視（外形監視）　はリダイレクト先を追跡しない場合もあったので気になっていました。

最後までご覧いただきありがとうございました。

本記事が誰かのお役に立てれば幸いです。